REMARKS 

Claims 14-15 and 23 are cancelled; claims 24-27 are new; thus, claims 1-13, 16-22, 
and 24-27 are all the claims pending in the application. Claims 1-23 stand rejected on prior 
art grounds; Figure 4 is objected. Applicants respectfully traverse these rejections based on 
the following discussion. 

I. The Objections to the Drawings 

The Office Action asserts that "Figure 4 fails to label the arrows branching off the 
decision boxes 22, 24, 27 and 29 with the word 'Yes' or 'No'" (Office Action, p. 2, para. 4). 
Applicants submit herewith a "Replacement Sheet" for Figure 4. In view of the foregoing, 
the Examiner is respectfully requested to reconsider and withdraw the objections. 

II. The Prior Art Rejections 

Claims 1-8, 10-13, 16-18, and 23 stand rejected under 35 U.S.C. §102(b) as being 
anticipated by Baker, et al. ("The Mirage NFS Router," A technical repot published by 
University of Arizona in 2002), hereinafter referred to as Baker. Claim 9 stands rejected 
under 35 U.S.C. § 103(a) as being unpatentable over Baker, in view of Katsurashima, et al. 
("NAS Switch: A Novel CIFS Server Virtualization," 2003), hereinafter referred to as 
Katsurashima. Claims 14-15 and 19-22 stand rejected under 35 U.S.C. §103(a) as being 
unpatentable over Baker, in view of IETF RFC 1094 ("Network File System Protocol 
Specification," version 2.0), hereinafter referred to as RFC 1094 and IETF RFC 791 
("Internet Protocol,"), hereinafter referred to as RFC 791. Applicants respectfully traverse 
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these rejections based on the following discussion. 

The claimed invention provides a communications network, wherein a client 
computer is adapted to send requests for storage to a communication virtualizer. The client 
computer is adapted to receive response packets from the communication virtualizer, wherein 
each response packet from includes a client identifier. In the rejection, the Office Action 
argues that the prior art of record discloses many features of the claimed invention. 
However, the "replies" of Baker do not include a client identifier. Instead, Baker merely 
discloses that the "replies" are mapped to a virtual file handle (VFH) before the reply is 
forwarded to the client. Furthermore, the response to the Remote Procedure Call (RPC) 
request in RFC 1094 does not include a client identifier. Instead, RFC 1094 merely discloses 
testing and timing the response from the server. Therefore, as explained in greater detail 
below, Applicants respectfully submit that the prior art of record does not teach or suggest 
the claimed invention. 

A. The Rejections Based on Baker 

Applicants traverse the rejections because Baker fails to teach or suggest the claimed 
features "wherein each response packet from said store computers includes said client 
identifier" as defined by independent claims 1 and 12. 

The Office Action asserts that the "replies" of Baker disclose the "response packets" 
of the claimed invention. However, Applicants submit that the "replies" of Baker do not 
include a "client identifier" (independent claims 1 and 12). Instead, Baker merely discloses 
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that the "replies" are mapped to a virtual file handle (VFH) before the reply is forwarded to 
the client (Baker, p. 4, §3.2). 

More specifically, as described on page 4, §3.2, of Baker, one of the core functions of 
the Mirage router is to map between the file handles produced by the Mirage router and the 
file handles produced by the NFS servers (Figure 5). The clients cannot be presented with 
the NFS server handles directly because there is no guarantee that the NFS servers won't 
generate the same handle for different objects. Mirage must perform a reverse mapping on 
NFS replies. Each physical file handle (PFH) in a reply must be mapped to the appropriate 
VFH before the reply is forwarded to the client. The most common reply to contain a PFH is 
the reply to the Lookup request that is used to resolve a file name into a file handle. Mirage 
looks up the PFH contained in the reply in the handle table and rewrites the NFS reply with 
the correct VFH before forwarding the reply to the client. Nevertheless, Baker fails to 
disclose that the replies include a "client identifier" (independent claims 1 and 12). 

To the contrary, as described in paragraph 0040 of Applicants' disclosure, a response 
may comprise multiple packets. Reference to paragraph numbers herein refer to the 
published patent application 2005/0198401, which are different than the paragraph numbers 
of the originally filed application. In a preferred embodiment, each packet comprising a 
response identifies the client 190, 200, 210 to which the response should be delivered. Upon 
receiving a packet comprising a response, a virtualizer 110, 120 forwards the packet to the 
client 190, 200, 210. When processing a multiple packet response, steps 8-11 of FIG. 3 are 
followed, except that steps 8-10 are redirected to response packet processing (rather than 
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response processing), and step 1 1 includes re-assembling the multiple response packets into a 
single response. 

As further described in paragraph 0059 of Applicants' disclosure, at least one packet 
of the response includes the request identifier. The virtualizer 1 10, 120, upon receiving the 
packet containing the request identifier, creates a timestamp for the response, and records it 
along with the request identifier, the timestamp of the request, and any other parameters that 
were recorded. This data may be retrieved later for various purposes, including performance 
analysis. 

Accordingly, Applicants submit that the "replies" of Baker do not include a "client 
identifier". Instead, Baker merely discloses that the "replies" are mapped to a virtual file 
handle (VFH) before the reply is forwarded to the client (Baker, p. 4, §3.2). Therefore, it is 
Applicants' position that Baker fails to teach or suggest the claimed features "wherein each 
response packet from said store computers includes said client identifier" as defined by 
independent claims 1 and 12. Further, it is Applicants' position that dependent claims 2-8, 
10-11, 13, 16-18, and 24-27 are similarly patentable, not only because of their dependency 
from a patentable independent claims, but also because of the additional features of the 
invention they defined. In view of the foregoing, the Examiner is respectfully requested to 
reconsider and withdraw the rejections. 

B. The Rejections Based on Baker and Katsurashima 

Applicants traverse the rejections because similar to Baker, Katsurashima fails to 
teach or suggest the claimed features "wherein each response packet from said store 
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computers includes a client identifier" as defined by independent claim 1 (from which claim 
9 depends upon). Instead, Katsurashima merely discloses a "NAS Switch" (which the Office 
Action asserts teaches the "virtualizer" of the claimed invention) that can provide "responses 
by itself to client requests in CIFS packets without using an NAS unit [which the Office 
Action asserts teaches the "network-attached store computer" of the claimed invention]" 
(Katsurashima, p. 2, §2). Nevertheless, nothing within Katsurashima teaches that the 
"responses" include a client identifier (independent claim 1). Applicants submit that 
Katsurashima is provided by the Office Action for the mere purpose of illustrating a 
communication network comprises a storage access protocol comprising a Common Internet 
File System (CIFS) protocol (Office Action, p. 11, item 2). In view of the foregoing, the 
Examiner is respectfully requested to reconsider and withdraw the rejections. 

C. The Rejections Based on Baker, RFC 1094, and RFC 79 1 
Applicants traverse the rejections because similar to Baker, neither RFC 1094 nor 
RFC 791 teach or suggest the claimed features "wherein each response packet from said store 
computers includes a client identifier" as defined by independent claim 12 (from which 
claims 14, 15, and 19-22 depend upon). 

The Office Action asserts that RFC 1094 discloses the "response packets" of the 
claimed invention. However, Applicants submit that the response to the Remote Procedure 
Call (RPC) request in RFC 1094 does not include a "client identifier" (independent claim 1). 
Instead, RFC 1094 merely discloses testing and timing the response from the server. 
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More specifically, RFC 1094 discloses that RPC provides a version number with each 
RPC request to the server (RFC 1094, §2). The RPC services allow server response testing 
and timing (RFC 1094, §2.2.1. and §A.5.L). For example, if the transport protocol drops the 
response for a Remove File operation, upon retransmission the server may return an error 
code of NFS ERR_NOENT instead of NFS_OK. But if the server keeps around the last 
operation requested and its result, it could return the proper success code. 

Furthermore, Applicants submit that RFC 79 1 does not teach or suggest a response to 
a client request, wherein the response includes a client identifier. RFC 791 is introduced by 
the Office Action for the mere puipose of illustrating an internet protocol for transmitting 
datagrams from sources to destination, wherein the datagrams may be fragmented (Office 
Action, pp. 13-15, item 3). Specifically, as described in section 1.1 of RFC 791, the internet 
protocol provides for transmitting blocks of data called datagrams from sources to 
destinations, where sources and destinations are hosts identified by fixed length addresses. 
The internet protocol also provides for fragmentation and reassembly of long datagrams. 
Nevertheless, nothing within RFC 791 discloses sending responses to the "sources" (which 
the Office Action asserts teaches the "client computers" of the claimed invention) that 
include a source identifier. In view of the foregoing, the Examiner is respectfully requested 
to reconsider and withdraw the rejections. 

II. Formal Matters and Conclusion 

In view of the foregoing, Applicants submit that claims 1-13, 16-22, and 24-27, all 
the claims presently pending in the application, are patentably distinct from the prior art of 
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record and are in condition for allowance. The Examiner is respectfully requested to pass the 
above application to issue at the earliest possible time. 

Should the Examiner find the application to be other than in condition for allowance, 
the Examiner is requested to contact the undersigned at the local telephone number listed 
below to discuss any other changes deemed necessary. Please charge any deficiencies and 
credit any overpayments to Attorney's Deposit Account Number 09-0441. 

Respectfully submitted, 



Dated: January 3, 2008 /Duane N. Moore/ 

Duane N. Moore 
Registration No. 53,352 

Gibb & Rahman, LLC 
2568-A Riva Road, Suite 304 
Annapolis, MD 21401 
Voice: (410) 573-6501 
Fax: (301)261-8825 
Customer Number: 29154 
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